home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
newsgroups
/
misc.19980901-19981211
/
000173_news@newsmaster….columbia.edu _Wed Oct 21 11:12:06 1998.msg
< prev
next >
Wrap
Internet Message Format
|
2020-01-01
|
6KB
Return-Path: <news@newsmaster.cc.columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id LAA26219
for <kermit.misc@watsun.cc.columbia.edu>; Wed, 21 Oct 1998 11:12:06 -0400 (EDT)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id LAA09464
for kermit.misc@watsun; Wed, 21 Oct 1998 11:12:05 -0400 (EDT)
Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.sys.hp.hpux,comp.protocols.kermit.misc
Subject: Re: Emulating VT100 PF1-PF3 with Kermit
Date: 21 Oct 1998 15:12:01 GMT
Organization: Columbia University
Lines: 112
Message-ID: <70ktk1$9q3$1@apakabar.cc.columbia.edu>
References: <70ih6b$1k7@hacgate2.hac.com> <70iscv$c8m$1@apakabar.cc.columbia.edu> <70j8j2$ldj$3@news.rz.uni-karlsruhe.de>
NNTP-Posting-Host: watsun.cc.columbia.edu
Xref: news.columbia.edu comp.sys.hp.hpux:93227 comp.protocols.kermit.misc:9369
In article <70j8j2$ldj$3@news.rz.uni-karlsruhe.de>,
Heribert Dahms <DAHMS@ifk20.mach.uni-karlsruhe.de> wrote:
: In <70iscv$c8m$1@apakabar.cc.columbia.edu> fdc@watsun.cc.columbia.edu writes:
: : In article <70ih6b$1k7@hacgate2.hac.com>,
: : KEITH OUTWATER /5G3110 <vac4050@PROBLEM_WITH_INEWS_GATEWAY_FILE> wrote:
: : : On my "real" VT100 terminal, PF1-PF3 are above the 7,8,9,-
: : : on the numeric keypad. My HPUX keyboard doesn't have these
: : : keys and F1-F3 on the HP keyboard (C3757) doesn't work
: : : with Kermit.
: : :
: : Right, Kermit can't do that because Kermit can't see the keys on
: : your keyboard. It can only see the characters that HP-UX generates
: : for them, one at a time.
: :
: : The way to get F-keys and other special keys to work as they do on
: : a VT100 or other kind of terminal is to map them that way outside of
: : Kermit, e.g. if you are using an xterm, use xmodmap. The precise
: : method depends on your window manager, the kind of xterm you are
: : running (if any), and what kind of keyboard you have.
:
: I usually just type the sequence for PF1 myself: <ESC>OP
: PF2: <ESC>OQ PF3: <ESC>OR PF4: <ESC>OS
:
Technically speaking, the problem is that C-Kermit, which runs on literally
hundreds of different UNIX (and non-UNIX) platforms, has only the lowly
"read(0,&c,1)" call available to read the keyboard. This works very well in
the sense that it doesn't matter whether you are using the workstation's
own keyboard in the text console or in an X or HP-VUE window, or if you are
coming in over a serial port, or on a Telnet, Rlogin, X.25, or other kind of
network connection. The drawback, of course, is that reading characters
from stdin does not give you access to the system- and keyboard-dependent
scan codes to let us know that you typed some special key. Any method of
accessing the keyboard at a lower level would be (a) necessarily nonportable,
and (b) nonfunctional if you were not actually using the workstation keyboard.
And to complicate the situation, I am not aware of any API available to a user
program to tell whether "stdin" is the real keyboard and screen (console or
xterm running on the console) or is associated with a communications
connection (serial or network).
A further, and more subtle, drawback is that even if you have used Xmodmap
or other method to map the appropriate escape sequences to F keys (or
whatever), C-Kermit still reads characters and not keystrokes, and therefore
has no way of knowing whether (say) <ESC> O P was produced by pressing one
key or three, and therefore whether to group them in a single write to avoid
spacings between them that could throw off user programs like VI that are
sensitive to such things.
: Hi Frank, since you seem to listen:
:
Sure I do. C-Kermit is fully supported on HP-UX by contract between HP
and the Kermit Project, and the Kermit Project takes its obligations
seriously.
: Hpterms and VTs of K95 under NT work quite fine, except one
: annoying thing: The page up and down keys scroll locally,
: which the original terminal emulators don't do!
: Typing <ESC>[5~ and <ESC>[6~ is too much finger acrobatic on a
: German keyboard, even for me 8-)
: How do I configure K95 to send page up and down to host, when
: pressed without any modifier key?
:
The PC keyboard is not the same as the (native) HP keyboard, and so there
must be a mapping. So that every user will not have to figure out how to
accomplish this individually, we provide a default mapping for each terminal
type in Kermit 95. The bad thing about defaults is that they rarely please
everybody. The good thing is that they can be changed.
The method for changing a terminal-specific key definition in K95 is:
1. Find out the keycode of the desired key. Use the "show key" command
to do this:
K-95> show key
Press key: <press-desired-key-here>
Key code \4385 Gray-PageUp (default) => Verb: \Kupscn
K-95>
Now you know the keycode and the current definition.
2. Use the "set terminal key" command to install the new definition:
K-95> set term key hpterm \4385 \27[5~
This means: when my terminal emulation is HPTERM, I want the Page Up
key to send <ESC>[5~.
3. Put the desired "set term key" in your K95CUSTOM.INI file.
: The booklet only mentions Ctrl-Gray-Page-Up (and -Down), but what
: is Gray on a German keyboard, please?
:
The current version of K95 is 1.1.17. It includes a vastly expanded user
manual, which you can read with your Web browser. You can patch up from
whatever version you have to 1.1.17 at:
http://www.columbia.edu/kermit/k95patch.html
: There's only left+right Strg (Ctrl), Alt and AltGr!
:
The USA keyboard has a gray (color) editing keypad below the Print Screen,
Scroll Lock, and Pause keys, and a gray arrow (cursor) keypad below the
editing keypad. The numeric keypad also has keys labeled the same way;
these labels apply when Num Lock is not on.
In any case, you can assign any desired functions to any desired keys --
whatever you want.
Note that K-95 is different from C-Kermit in this respect, since K-95
really *does* have access to the physical keyboard via well-defined Windows
(or OS/2) APIs.
- Frank